feat: add optional you.com MCP template to setup wizard - #1107
feat: add optional you.com MCP template to setup wizard#1107mouse-value-add wants to merge 6 commits into
Conversation
Adds a You.com entry to the MCP wizard template list. The template builds a remote HTTP config pointing at https://api.you.com/mcp with an optional YDC_API_KEY bearer header; leaving the key empty falls back to the keyless free profile (https://api.you.com/mcp?profile=free).
will-lamerton
left a comment
will-lamerton
left a comment
There was a problem hiding this comment.
Thanks for this - the shape follows github-remote correctly and the tests are good. I verified both endpoints are live: the ?profile=free URL does initialize keyless (serverInfo: You.com v3.7.0), and the plain URL 401s without a bearer and works with one. CI is green and the spec passes locally (38/38).
One blocker plus some polish.
Blocking: editing a saved You.com server silently drops the API key.
The edit flow in source/wizards/steps/mcp-step.tsx:261 only repopulates an apiKey field from server.env. This template stores its credential in headers.Authorization, so on re-edit the field comes up blank. Since it is required: false, pressing Enter through it is accepted and buildConfig rewrites the config to the keyless free profile, quietly downgrading a user off their paid key. github-remote has the same gap but its field is required: true, so the wizard forces re-entry instead of losing data.
Simplest fix is to extend that mapping to read the bearer back out of server.headers?.Authorization when the field is named apiKey.
Non-blocking:
- The template lands at
mcp-templates.ts:381, betweenduckduckgoandgit, while the other remote templates are grouped at lines 251-302. It renders fine because the wizard filters bycategory, but it should move up next togithub-remote. - The spec adds
youtoremote templates: have no required fieldsbut not toremote templates: use http transport(line 482). Worth keeping the two lists in sync. - Unlike
deepwiki/context7/github-remote, there is noserverNamefield, so the name is hardcoded toyouand you cannot configure a free and a keyed instance side by side. Fine if deliberate, just flagging it. docs/configuration/mcp-configuration.md:246lists the bundled templates. It ends in "etc." so this is optional, but adding You.com there would keep it current.- The branch is behind
mainand will need a rebase before it can land.
FWIW, one thing worth knowing about the upstream server: with an invalid bearer, initialize and tools/list still return 200 and only tools/call fails with Error code: 401. So a typo'd key produces a server that looks healthy in /mcp and fails at call time. Not something this PR can fix, but it makes the silent-key-drop above harder for a user to notice.
…emplate with remote templates - mcp-step.tsx: repopulate the apiKey field from server.headers.Authorization (Bearer) when the template stores its credential in headers instead of env, so editing a saved You.com (or GitHub remote) server no longer silently drops the key and downgrades to the keyless free profile - mcp-templates.ts: move the you template next to github-remote with the other remote templates, and add a serverName field so a keyed and a free-profile instance can be configured side by side (default: you) - mcp-templates.spec.ts: cover serverName default and custom name, and add 'you' to the http-transport list to keep the two remote-template lists in sync - docs: mention You.com and DuckDuckGo in the wizard template list Rebased onto latest main.
|
Thanks for the thorough review — all points addressed in a3d3869 (plus a merge of latest main, so the branch is current):
39/39 template spec tests pass, |
will-lamerton
left a comment
will-lamerton
left a comment
There was a problem hiding this comment.
Thanks, most of this is sorted. I verified locally on a3d3869f: 39/39 in mcp-templates.spec.ts, tsc --noEmit clean, biome clean. Grouping, serverName, spec-list sync and docs are all good, and I traced the bearer prefill through beginTemplate -> masked TextInput, so the key does survive a re-edit now.
Two things before this lands.
1. The key-drop fix doesn't cover the case serverName was added for.
Edit resolves the template with MCP_TEMPLATES.find(t => t.id === server.name) at source/wizards/steps/mcp-step.tsx:230. Under the default name you that matches and your fix works. Under any custom name (you-paid) it misses and falls through to the custom template, which has no apiKey field and whose buildConfig (source/wizards/templates/mcp-templates.ts:491) never writes headers at all, so the Authorization header is dropped entirely. That is worse than the original bug, and it is exactly the "keyed + free profile side by side" scenario the new field exists to enable, since one of the two must be custom-named.
The path is pre-existing and hits context7 / deepwiki / github-remote custom names too, so I'm happy for the real fix to be a follow-up. But I don't want to ship a field whose documented purpose silently eats credentials. Either persist a template id on the saved server (or match on tags) so custom-named instances resolve back to their template, or drop serverName from this PR and keep the name hardcoded to you.
2. The comment overstates coverage.
source/wizards/steps/mcp-step.tsx:262 says remote templates "like you and github-remote store the credential there". The new branch keys off field.name === 'apiKey', but github-remote's field is githubToken (mcp-templates.ts:281), so it never fires for that template regardless of whether required is relaxed. Harmless today, but please correct the comment so nobody relies on it later.
Also: only changeset-check and label have reported on the new head, the main pr-checks workflow hasn't run on a3d3869f. And the branch is 18 commits behind main again, no conflicts.
… on edit Wizard-built configs now stamp the originating template's id (templateId) onto the saved server. The edit flow prefers it over name-based lookup, so editing a custom-named instance (e.g. you-paid) re-opens the original template's form instead of falling through to custom — whose buildConfig never writes headers, silently dropping a saved bearer token on re-save. Resolution falls back to tag matching (transport-checked, so the github-remote tag 'github' cannot resolve an http server to the stdio GitHub template) and then to the server name, covering configs written before the stamp existed. Also tightens an overstating comment about the apiKey prefill path: only templates with a field literally named apiKey (today just you) take it; github-remote uses githubToken and never did.
|
Both points addressed in 57cd138 (also merges the 18 commits of 1. Template resolution for custom-named instances. The wizard now stamps the originating template's id ( const templateId = resolveMcpTemplateId(server);
const template =
(templateId ? MCP_TEMPLATES.find(t => t.id === templateId) : undefined) ||
MCP_TEMPLATES.find(t => t.id === editingServerName) ||
MCP_TEMPLATES.find(t => t.id === 'custom');When there's no stamp (hand-edited configs, or files written before this change), Spec coverage: a new integration test deep-links into a custom-named 2. Comment corrected. It now says only templates whose credential field is literally named I went with persisting the id rather than dropping |
|
Left a comment on the pr-checks workflow situation on the PR — nothing more needed from my side, the branch itself is green (tsc --noEmit clean, biome clean on the touched paths, and 105/105 wizard template/step tests pass locally on 57cd138, matching your verification). The pr-checks workflow still hasn't reported on the last two heads because it runs from the base repo against cross-repository fork heads — happy to rebase onto main again if that helps trigger it, just say the word. |
|
Merged the latest main (the status-badge update) into the branch so it's current again — 3f05a6c. Everything still green locally on the merged head: tsc --noEmit, biome, and 105/105 wizard tests. |
2 participants
What
Adds a You.com entry to the MCP wizard template list (
MCP_TEMPLATES), next to Brave Search and DuckDuckGo. I noticed the wizard already curates remote HTTP servers like DeepWiki and Context7 throughremoteHttpTemplate, so this follows that same pattern rather than introducing anything new.The template builds a remote HTTP config pointing at
https://api.you.com/mcp:YDC_API_KEYbuilds an authenticated config with aAuthorization: Bearer ***header (same shape as thegithub-remotetemplate's header handling).https://api.you.com/mcp?profile=free, so basicyou-searchworks with zero signup.Once connected, the agent gets You.com's
you-search/you-contents/you-researchtools for web search, URL reading, and cited research — useful for the same "verify current library versions / unknown APIs" cases the built-in tools don't cover.Why it's safe
/settings mcp.sensitive: truelike the other credential fields.Changes
source/wizards/templates/mcp-templates.ts— newyoutemplate (36 lines, one registry entry)source/wizards/templates/mcp-templates.spec.ts— 4 tests: authenticated config, keyless fallback, whitespace trimming, blank-key fallback; also addedyouto the "remote templates: have no required fields" list.changeset/youcom-mcp-wizard-template.md— minor changesetValidation
pnpm test:ava source/wizards/templates/mcp-templates.spec.ts— 38/38 pass (incl. the dead-host guard and transport-field checks)pnpm test:types— cleanpnpm test:format/pnpm test:lint— cleannode scripts/validate-changesets.js— cleanpnpm test:knip— clean (pre-existing hints only)Live-endpoint note: I could not run the wizard interactively here, but the config shape matches the working
context7/deepwikiHTTP entries, and both You.com endpoints (https://api.you.com/mcpand?profile=free) are live remote servers — easy to sanity-check with/mcpafter installing the template.Happy to adjust the shape if you'd rather split this into two templates (authenticated vs. free) or use the simpler
remoteHttpTemplatewithout the optional-key logic.